Description

Addresses defect 2 of #2388 (the dead grow fast path). The other three defects in that issue are not touched here, so this does not close it.

modify_allocation() asks cuMemAddressReserve for the address immediately after the current range, then checks whether the driver granted that exact address before taking the fast path:

res, new_ptr = driver.cuMemAddressReserve(..., int(buf.handle) + aligned_prev_size, 0)

if res != driver.CUresult.CUDA_SUCCESS or new_ptr != (int(buf.handle) + aligned_prev_size):

new_ptr is a CUdeviceptr. That type defines __int__ and __repr__ but no __eq__ or __richcmp__ (cuda_bindings/cuda/bindings/driver.pyx), so comparing it against a plain int falls back to identity and is unconditionally unequal. The guard is therefore always taken, _grow_allocation_fast_path is unreachable, and every grow runs the slow path: a full re-reserve plus remap, with the buffer's base pointer changing even when the driver did grant a contiguous extension.

The fix is the int() conversion suggested in the issue.

Behavior change, not a pure cleanup

This makes a previously unreachable path live. After it, a grow the driver can satisfy contiguously preserves the base pointer instead of moving it. That is the documented intent of the fast path, but it has never actually executed, so it deserves explicit attention in review. Added to the 1.2.0 release notes for that reason. The existing test asserting a grown buffer's pointer may change (test_vmm_allocator_grow_allocation) still passes, since it only requires a non-null handle.

Since the fast path becomes reachable for the first time, I checked the one line in it that looked risky. buf._size = new_size still carries a TODO: #2049 This is a real bug, accessing _size which doesn't exist. That TODO is stale on the Cython side: _size was moved into a cdef public block in _buffer.pxd by #2216 and #2049 is closed, so the assignment works on a real Buffer. The # type: ignore[attr-defined] is still required because _buffer.pyi does not expose _size, so I left both the ignore and the TODO alone rather than widening this PR. Happy to clean that up separately if you want it.

Testing

test_vmm_allocator_grow_dispatches_to_fast_path stubs cuMemAddressReserve to grant exactly the address that was requested and asserts the dispatch reaches the fast path. It should fail on current main, recording "slow". It follows the stubbing style of the adjacent test_vmm_allocator_grow_allocation_fast_path.

That existing test covered _grow_allocation_fast_path by calling it directly, which is why the broken dispatch was invisible: it stays green whether or not modify_allocation can actually reach the helper. The gap was coverage of the decision that reaches it.

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.